System and method for building intuitive clinical trial applications

ABSTRACT

The present invention allows clinical trial organizers to operate a platform for creating trial specific custom mobile applications at a price point that would not be possible if the application were created by programmers on a trial-by-trial basis. The invention shortens build time by creating a hierarchy of questions that changes the next question posed to the user based upon their answer to a previous question thereby reducing the number of questions the user must answer while providing the application creation platform with the detailed information relevant to a specific clinical trial. The platform uses a simulation builder that provides a test version of the application to the user mobile device during the application creation process thereby allowing the user to see the layout of the application as they progress through the building process. While building the application, the user can create a simulated version of the application in real time deliver the same to the mobile device of the user. The system creates a handshaking process that allows the user to create annotations and/or edits in the simulated application that are communicated back to the building platform. Changes made in the simulated application will affect the landing page the user sees when returning to the building platform. The system will collect usability data from a clinical trial application on a plurality of trial subject and trial organizer mobile devices. The system can measure variables such as time on page, misentries, and missed selections of icons to determine common trouble spots for users. That data may be used to redesign the interface or process flow of the application to optimize usability

BACKGROUND OF THE INVENTION Field of the Invention

The present invention generally relates to mobile applications. Morespecifically, the present invention concerns the creation of customizedmobile applications for clinical trials without the need for extensiveapplication programming knowledge.

Description of the Related Art

Various means for application testing or creation of a sandbox are knownin the art. These prior art solutions suffer, however, from extendedbuild times and lack of specificity concerning a given test or trial.Both also require extensive knowledge of software development andcoding, skill sets that are often exclusive from the clinical testingrealm, which has nevertheless become increasingly dependent upon mobiledevices and application software running on the same. Prior artmethodologies also require weeks if not months of development and arenot scalable or flexible with respect to changes in demand or focus.

Mobile application testing is a process by which software applicationsdeveloped for a handheld or other mobile devise are tested forfunctionality, usability, and consistency. Mobile application testing,however, suffers from a number of testing demands that are often notrelated to the needs of a clinical study. For example, typical mobileapplication testing involves not only functional testing, but laboratorytesting, performance testing, memory leakage testing, interrupt testing,installation testing, certification testing, security testing, locationtesting, OST, and load testing. While potentially useful information insome environments, this information is less germane to a clinical testapplication.

Sandboxes on the other hand are testing environments that isolateuntested code changes and experimentation the production environment orcode repository. Sandboxing protects live servers and data frominstances where reversion because of a build error may be difficult toeffectuate. Sandboxing is ineffective, however, because it replicatesminimal functionality needed to accurately test an application or codeunder development. In many instances, this minimal realm of operabilityis not sufficient to effectuate or understand whether a clinical testingapplication is ready for release, achieves a desired purpose, engages auser, or even operates in conjunction with a mobile device.

There is a need in the art for systems and methods related to improvedapplication creation platforms. This need includes creating engaginguser experiences, end-to-end technology suites, and turn-key solutionsthat allow for successful remote patient and clinical research studies.The need further includes intuitive design configuration, easilyreviewed, approved, and scheduled study launches, and accessing andextracting data and study performances in real time. All of this wouldideally occur in a context comprehensible to individuals orprofessionals that are not software and hardware engineers but thatnevertheless need access to hardware and software applications designedfor their specific needs.

SUMMARY OF THE CLAIMED INVENTION

In a first claimed embodiment of the invention, a method for remoteclinical trial organization is recited. In the method, a response isreceived for at least a first question designed to identify one or moreelements necessary to complete a clinical trial in an application basedtesting environment. A second question is posited based on at least areceived response for the at least first question, whereby the responsesto the at least first and second question are used to access a databaseof elements for constructing the application for the clinical trialapplication. These elements include clinical and consumer medicalmonitoring devices relevant to the trial. Data collected from a trialsubject is processed utilizing the application for the clinical trialand any corresponding clinical and consumer medical monitoring devices.The application is authored by a software platform operating inconjunction with the clinical trial. The clinical trial application ismodified responsive to the processed data collected from the trialsubject.

In a second claimed embodiment of the invention, a system for building aclinical trial application is recited. The system includes a user devicefor providing clinical trial requirements and a software platformexecuting to posit a series of iterative questions that drive buildingthe clinical trial application in accordance with the clinical trialrequirements. A response to each question determines a next positedquestion in the series. The clinical trial application is built inreal-time and responsive to the posited series of iterative questions.The clinical trial is then simulated in real-time and launched to userdevices. Data is received from the user devices and captured by theclinical trial application, which may be modified responsive to thereceived data captured by the clinical trial applications.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a system for creation of applications for clinicaltrials.

FIG. 2 illustrates a workflow for application construction software.

FIG. 3 illustrates a workflow for a question ordering module.

FIG. 4 illustrates a workflow for a review module.

FIG. 5 illustrates a workflow for a simulation feedback module.

FIG. 6 illustrates a workflow for a use module.

FIG. 7 illustrates exemplar mobile device interactions in the context ofa use module.

FIG. 8 illustrates an application simulation interface.

FIG. 9 illustrates an application review interface.

FIG. 10 illustrates a usability database.

FIG. 11 illustrates a building database.

DETAILED DESCRIPTION

Systems and methods for application creation platforms are disclosed.These platforms allow for the creation of engaging user experiences withan end-to-end technology suite and turn-key solutions. The disclosedinvention allows for intuitive design configuration, the review,approval, and scheduling of study launches, and accessing and extractingdata and study performances in real time. The overall end-result issuccessful remote patient and clinical research studies. The studies mayutilize advanced tokenization techniques that are compliant with datasecurity requirements that are HIPAA and FDA approved. The currentdisclosed platform may likewise be integrated into existing data systemsthat are scalable while remaining customer configurable to suit theindividual needs of a given study or user.

FIG. 1 illustrates a system 100 for creation of applications forclinical trials. The system 100 of FIG. 1 further allows for organizingand reporting in compliance with various privacy and regulatoryrequirements that may pertain to the administration of a particularclinical trial (e.g., HIPAA or the FDA). The system 100 of FIG. 1includes a user terminal 105 with an application building interface 110,subject mobile devices 115 with application interfaces 120, a usermobile device 125 with an application simulation interface 130, and astudy building platform 135.

Platform 135 and the aforementioned terminal 105 and devices 115 and 130may be communicatively coupled over a communications network 140 such asthe Internet. Communications network 140 may not necessarily be limitedto the Internet. Network 140 may include any number of local-area andwide-area networks, open- and proprietary-networks, wired and wirelessnetworks, and networks that may or may not be subject to encryption orthe use of VPNs or tunneling.

It should further be noted that in various implementations, platform 135and terminal 105 and devices 115 and 130 may not be communicativelycoupled at the same time. For example, in some instances only terminal105 may be connected to platform 135 while at other times only subjectmobile devices 115 may be connected to platform 135. In other examples,a single subject mobile device 115 may be communicatively coupled to theplatform 135 whereas multiple such devices 115 may be connected atothers. All of the aforementioned terminals and mobile devices includerequisite computing componentry such as processors, memories, andcommunications interfaces to allow for receipt, transmission, andprocessing of data such that it may be displayed, accessed, andmanipulated through the appropriate GUI and other input/output devicesand/or utilized by platform 135.

The study building platform 135 facilitates generation of applicationsthat allow for user engagement as part of an overall end-to-endtechnology suite that can provision a complete product or service readyfor use as part of a turn-key solution. Platform 135 may be integratedinto an existing data system such that the system 100 is scalable whileremaining customer configurable. In this way, the individual needs of agiven study or user may be readily facilitated. Platform 135 may furtherfacilitate privacy and data security compliant studies as may berequired by the likes of HIPAA and the FDA by utilizing advancedtokenization techniques whereby a sensitive data element may besubstituted with a non-sensitive equivalent that has no extrinsic orexploitative value.

Platform 135 as illustrated in FIG. 1 includes application constructionsoftware 140. Platform 135 further includes an application buildingdatabase 145, application element database 150, usability database 155,construction question database 160, and documentation database 165.Construction software 140 as illustrated in FIG. 1 includes a suite ofmodules, including question ordering module 170, simulation module 175,feedback module 180, review module 185, and real-world use module 190.It should be noted that embodiments of the invention may in someinstances include all of the modules. In other instances, fewer modulesmay be included. Similarly with databases as various embodiments may useall or fewer of the databases currently illustrated in FIG. 1. Further,embodiments of the present invention may combine the functionality ofcertain application modules and/or databases into singular operatingdatabases or modules. Platform 135 also envisions the presence of anyrequisite computing componentry such as processors, memories, andcommunications interfaces to allow for receipt, transmission, andprocessing of data such that it may be displayed, accessed, andmanipulated through the appropriate GUI and other input/output devicesand/or utilized by terminal 105 and devices 115 and 130.

The building database 145 includes completed applications, third-partyapplications, and storage for applications under construction.Applications stored in database 145 may be used as foundations forfuture applications or to provide design studies or context for thesame. Various ancillary third-party applications offering differentfunctionalities may likewise be stored in said database. In progressapplications may be maintained here in the event that an application isnot completed or further queries or real-world data are required tocomplete the build or further instantiation of the same.

The application element database 150 includes the necessary data andcomponentry necessary to build a mobile, tablet, or other patient deviceapplication. Database 150 includes the core elements of a software ormobile application that may instantiate further aspects or builds of theapplication whereby code is effectively writing more code. As a resultof information maintained by database 150, an application effectively‘builds’ itself based on various requirements of the application as maybe identified from information provided by or accessed from constructionsoftware 140 and or databases 155-165.

Patient devices are inclusive of wearable devices and other mobilepatient monitoring technology that may be worn, carried, implanted, orotherwise transported by a patient. Such hardware may communicate with atethered mobile device such as subject mobile devices 115 or othertransmitting device through known communications protocols. That devicemay, in turn, communicate with platform 135. In some instances, thepatient monitoring device may be the mobile device 115.

Usability database 155 stores real-world usage data collected fromsubject mobile devices once an application has been built in conjunctionwith element database 150. While illustrated as a part of platform 135,this database may be maintained by a third-party or at a secure offsitelocation to comply with certain privacy or statutory requirements.Construction question database 160 contains questions used by thequestion ordering module 170 to guide the creation of the application inconjunction with element database 150. The question ordering moduledetermines those elements in the element database 150 that should beused in conjunction with element database 150 based upon answers toposited questions.

The user administering a clinical trial and building an applicationcorresponding to the same accesses system 100 and platform 135 from (forexample) the user terminal 105, which may be a personal computer.Terminal 105 may be directly connected to platform 135 through a localarea network connection. Platform 135 may alternatively be cloud-basedor a SAAS application that instantiates from a server farm on an asneeded basis.

The construction software 140 of platform 135 commences execution whenthe user logs in with proper credentials. Software 140 calls questionordering module 170, which will select a series of questions fromconstruction question database 160 and that are presented to the user byway of interface 110. Each ‘next question’ is presented based on theanswer to a previous question or a series of questions such that variouscomponents, features, and documentation (as may be maintained bydatabase 165) are ultimately integrated into the study application byway of a catalog of application and back-end databases necessary orancillary advantageous to the needs of a given study. The answers tothese questions will determine which elements and modules are drawn fromthe element database 150 and building database 145 to finally constructthe clinical trial application. This may include substantive featuressuch as patient data collection as well as more cosmetic features suchas application content and layout. In some instances, it is envisionedthat the layout may drive the quality of patient feedback thus causingthe cosmetic aspects to become hybrid substantive features.

The simulation generation module 175 creates a simulation of theapplication based upon the results of the question ordering module 170,the build from element database 150 and, as needed, application buildingdatabase 145. That simulation is sent to the mobile device 125, whichmay be a secure mobile device for real-world testing of clinical trialapplications. User device 130 may be ‘locked down’ or have certainsecurity functions installed to maintain the security or control of theyet-to-be-released clinical trial application, including a simulationGUI 130 that may allow for controlled input of output differing from areal-world interface like that found on devices 115 and correspondingGUI 120.

Application software 140 of building platform 135 runs the simulationfeedback module 180, which polls the application simulation GUI 130 ondevice 125 for a user test-selection. When the user selects an elementin the simulation, the element database 150 is queried to identify thepossible changes that can be made to that component of the applicationor trial. These changes may include removing or replacing applicationelements, changing the color of the elements, changing the arrangementof the elements as well as tracking or collection of certain data fromvarious resources or hardware components or otherwise softwareapplications that may ultimately be present on a user device likesubject mobile device 115. Those options and the results of any changesmay be displayed for the user on GUI 125 or, alternatively, at terminal105 and GUI 110, which may run in parallel with device 125 during thebuild stage.

When the user selects which type of modification they wish to make byway of interface 125, the further options or output from thatmodification are likewise displayed such that a user has a real-timeunderstanding of changes to the application and potential study results.Once the edit has been selected, the option to end edits is displayedfor the user. If the user selects the end edits option the simulationfeedback module 180 ends its execution and returns control of the buildto the construction software 140. The user can continue to selectelements as they navigate through the ordering module 170, correspondingsimulations as generated by simulation generation module 175, andsimulation feedback from module 180, which tracks revisions to theapplication study.

Once the user completes the application simulation on a test mobiledevice, the user returns to the application building interface 110 onthe user terminal 105. The user will then be moved into the review phaseof the application and clinical trial build as driven by review module185. Module 185 will execute to walk a user through a process to reviewtheir study, determine any gaps or recommended areas to address, andprovide a scan of their study to confirm all required elements/sectionsare completed as may be required by various industry, clinical, or otherscientific standards. Based on the previous selections by the user, thesystem identifies all third-party or extraneous applications andhardware that may or must provide data relevant to the study.

A list of applicable or available user mobile devices (115) is thenpresented to the user on the application building interface 110.Specialized or study specific clinical devices may be sourced anddistributed to trial subjects. Consumer devices such as iPhones,wearables, or other health tracks may be allowed by the study organizerdepending on the nature of the clinical study. In these cases the trialsubject will be presented with the list of allowed consumer devicesthereby allowing for provisioning data directly through the built andinstalled clinical trial application to the study platform. This sectionalso provides the user with automated documentation (e.g., IRB/ECsubmission information, project plans, and business cases) from database165 that may be necessary to conduct or facilitate the study.

The end of the review module 185 execution allows the user to approvethe launch of the application. If the user does not approve theapplication for launch, the system reverts to the question orderingmodule 170 for potential further application development. When the userdecides the application is ready to be published for download orinstallation by subjects or supervisors in the clinical trial, theplatform then directs the user to a study portal (not shown) providingstatus on their submissions and completed launch. Upon approval by adistribution platform (e.g., an application store for a potential mobilecommunity) or installation for clinical devices, data begins to flowthrough the portal providing research information, patient progress, andanalytics. That data may be maintained by platform 135 in usabilitydatabase 155 or in a secure database, which may be maintained by apatient, study site, hospital, university, or other third-partyprovider.

Construction software 135 then begins polling for real world applicationusage by way of module 190 from any mobile devices 115 hosting theapplication and providing data. When real world application usage datais available as determined by such polling, the usability database 155will be updated with the new information. Polling may be on-demand,scheduled, random, or event-based with respect to some occurrence on auser device 115 or based on network conditions at the platform 135.

In an exemplary and non-limiting analysis of use data, for eachscreen/element/question/login/prompt that is accessed on a subjectmobile device 115 the usage data will be recorded, which may includeinformation such as the time spent on that element, the number of clickson that element and if the subject completed or abandoned that element.The usability database 155 will have the average for each of thesemeasures and more for each such screen/element/question/login/prompt andthe number of data points it has been provided to calculate thoseaverages as well as other data that may be passively recorded by thedevice.

A first value stored in database 155 is examined by the use module 190,which may be the completion percentage for a particularscreen/element/question/login/prompt. If the completion percentage isbelow a user defined threshold, such as 70%, an alert is sent to theuser as this screen/element/question/login/prompt is apparently causingan unacceptable number of trial subjects to not complete that portion oftheir assessment. This alert can be sent in a variety of ways, includingtext or email, but will include, or include a link to, a report aboutthe real world usage and a link to the portion of the question orderingmodule 170 that relates to the screen/element/question/login/prompt thathad the unacceptably low completion percentage.

If the completion percentage is above the user defined threshold, a nextvalue is examined, which may be the average time to complete thescreen/element/question/login/prompt. If that is below a user definedthreshold, the system returns to the construction software 140 and pollsfor more real world usage data. If the average time to complete is abovethe threshold the number of data points that were used to produce thisaverage time to complete is examined to determine if the sample size islarge enough. If the number of data points is below a preset thresholdfor sample size the system returns to the construction software andpolls for more real world usage data.

If the sample size is large enough for the data to be meaningful, thenumber of elements on the problem screen is examined. If the number ofelements on the screen is above a user defined threshold the elementsare split into two screens and the system returns to the constructionsoftware 140 and polls for more real world usage data. If the number ofelements does not exceed the threshold, the location and sequence of theclicks subjects made on that screen are examined. The order and locationof those clicks are then used to rearrange the elements on the screen sothat the order in which they are designed to be completed matches themost frequent order and location of the real world clicks.

If the click locations are not indicative of a layout problem—forexample there is no clear pattern in the real world clicks—the systemsends an alert to the user similar to the alert sent when the completionpercentage drops below the acceptable threshold. In both cases, eitherafter the alert or after the elements is rearranged on the screen, thesystem 100 returns to the construction software 140 and polls for moreusage data.

FIG. 2 illustrates a workflow 200 for application construction software140. Software 140 and corresponding workflow 200 may be used in thecontext of the system 100 illustrated in FIG. 1. The constructionsoftware commences execution when the user logs in at step 205. Questionordering module executes at step 210. This module—as discussed in thecontext of FIG. 1—will select the next question from the constructionquestion database based on the answer to a previous question. Theanswers to these questions will determine which elements and modules aredrawn from the element and other databases to construct the applicationfor a clinical trial. In this fashion the application content and layoutwill be determined as will various data acquisition functionalities.

Next, the simulation feedback module creates a simulation of theapplication based upon the results of the question ordering module atstep 215. That simulation is sent to the user mobile device and theconstruction platform runs the simulation feedback module at step 220.Once the user is done with the simulation interface on their mobiledevice, the user returns to the application building interface on theuser terminal. The user will then be moved into the review module, whichexecutes at step 225.

This module will walk the user through a process to review their study,determine any gaps or recommended areas to address, and provide a scanof their study to confirm required elements/sections are completed. Thissection also provides the user with their automated documentationsupporting their other required processes. The end of the review moduleallows the user to approve the launch of the application at step 230. Ifthe user does not approve the application for launch, the system revertsback to the question ordering module at step 210. When the user decidesthe application is ready to be published for download by subjects orinstallation on devices in the clinical trial, the platform then directsthe user to the study portal (not depicted) at step 235 to provide ananticipated launch date, evidence of legal authority to commence thestudy, and any other institutional or board approval required for thesame.

Upon store or install approvals, the application is installed at step240. Data will ultimately flow through a portal providing clinical studydata, patient progress, and analytics such as future machine learningand artificial intelligence on the generated data; management of saiddata may occur at step 245. This portal is where the study is managedfor the customer and includes major aspects of the study such asdocumentation, timeline, prototype download, and schedule of events. Theapplication construction software will also poll for real world usage atstep 250 from any mobile devices that downloaded the application at step240. When real world application usage data is available the applicationconstruction software will launch the real world application use module255 to provide that analysis as described in the context of FIG. 1.

FIG. 3 illustrates a workflow 300 for a question ordering module. Thequestion ordering module takes the questions from the constructionquestion database and poses them to the user in an order based upon theanswers to previous questions. Before presenting the user with questionsspecifically related to application construction, the system offers theuser two optional question sections: the design case and the businesscase.

If the user goes through the design section, the system will take themthrough a process of answering questions and workshop/video completionthat contributes to the business case build/export. The user can then gothrough the business case section, during which they will have theopportunity to answer questions that build and export a remote patientresearch study business case specific for a project. After the twooptional modules, the user will go through the construction specificquestions, which are not optional. Based on answers and theidentification of required study elements, including but not limited tobranding, credentials, eConsent, and legal requirements, and completionof queries customized for the specific study as well as identificationof optional study components such as ePRO, eDRO, medical devices, andtele-health, the user is presented with the required and optionalelements for their study. Selections update the building database andthe system executes construction software.

FIG. 4 illustrates a workflow 400 for a review module. The review modulewalks the user through a process to review their study, determine anygaps or recommended areas to address, and provide a scan of their studyto confirm all required elements/sections are completed. The workflowbegins by identifying all questions/answers that were asked and answeredby the user in the question ordering module. The elements that should bepresent based upon the questions asked and the answers given are thenidentified as this information is in the application element database.That list of elements is then compared to the elements that are in thecurrent application in the application construction database. If thereare any required elements missing, they are presented to the user. Ifthe user agrees, the required elements are introduced into theapplication. If the user does not agree with the suggestion, the systemwill return to the question ordering module.

Optional elements that should be present based upon the questionordering module are then presented to the user. Optional elements thatthe user selects are then inserted into the application in theapplication building database. Based on all of the previous selectionsby the user, the system identifies ancillary devices and hardware suchas clinical and consumer medical monitoring devices, smart watches,activity monitors, and blood glucose meters that can provide datarelevant to the study from the application element database. Theidentified list of devices is then presented to the user on theapplication building interface. Clinical devices are sourced anddistributed by the system to trial subjects. Consumer devices areallowed by the study organizer. In these cases the trial subject will bepresented with the list of allowed consumer devices, and they can opt into allow the data to be fed directly through the clinical trialapplication to the study platform.

The document database is then examined to identify documentation thatcorresponds to the elements in the application. The user is thenpresented with the identified documentation such as internal reviewboard and ethics committee submission packets, project plans, businesscases, and the like supporting the required processes to conduct aremote patient study. The user is then given the opportunity to approvethe launch of the application. The user decision is then sent back tothe app construction software.

FIG. 5 illustrates a workflow 500 for a simulation feedback module. Thesimulation feedback module creates a simulation of the application basedupon the results of the question ordering module. That simulation issent to the user mobile device and the application construction platformruns the simulation feedback module. The simulation feedback modulepolls the application simulation for a user selection. When the userselects an element in the simulation, the application element databaseis queried to identify the possible changes that can be made to thatelement, including but not limited to, removing or replacing theelement, changing the color of the elements, or changing the arrangementof the element. When the user selects which type of modification theywish to make, the options for that modification are displayed on theapplication simulation interface.

Once the edit has been selected the option to end edits is displayed forthe user. If the user selects the end edits option the execution of thesimulation feedback module ends and returns to the applicationconstruction software. The user can continue to select elements as theynavigate through the application simulation and the simulation feedbackmodule will continue to allow them to edit or rearrange theirapplication.

FIG. 6 illustrates a workflow 600 for a use module. The use moduleexecutes when it receives application usage data from subject mobiledevices. The usability database will be updated with the newinformation. For each screen/element/question/login that is accessed ona subject mobile device, the usage data may include the time spent onthat element, the number of clicks on that element and if the subjectcompleted or abandoned that element. The application usability databasewill have the average for each of these measures for eachscreen/element/question/login and the number of data points it has beenprovided to calculate those averages.

The first value that is then examined by the real world use module isthe completion percentage for the screen/element/question/login inquestion. If the completion percentage is below a user definedthreshold, in this example 70%, an alert is sent to the user as thisscreen/element/question/login is causing an unacceptable number of trialsubjects to not complete that portion of their assessment. This alertcan be sent in a variety of ways, including text or email, but willinclude, or include a link to, a report about the application usage dataand a link to the portion of the question ordering module that relatesto the screen/element/question/login that had the unacceptably lowcompletion percentage.

If the completion percentage is above the user defined threshold, thenext value examined is the average time to complete thescreen/element/question/login. If that is below a user definedthreshold, the system returns to the construction software and polls formore real world usage data. If the average time to complete is above thethreshold the number of data points that were used to produce thisaverage time to complete is examined to determine if the sample size islarge enough. If the number of data points is below a preset thresholdfor sample size the system returns to the construction software andpolls for more real world usage data.

If the sample size is large enough for the data to be meaningful thenumber of elements on the problem screen is examined. If the number ofelements on the screen is above a user defined threshold the elementsare split into two screens and the system returns to the appconstruction software and polls for more real world app usage data. Ifthe number of elements does not exceed the threshold, the location andsequence of the clicks subjects made on that screen are examined. Theorder and location of those clicks are then used to rearrange theelements on the screen so that the order in which they are designed tobe completed matches the most frequent order and location of the realworld clicks. If the click locations are not indicative of a layoutproblem, for example there is no clear pattern in the real world clicks,the system sends an alert to the user similar to the alert sent when thecompletion percentage drops below the acceptable threshold. In bothcases, either after the alert or after the elements are rearranged onthe screen, the system returns to the construction software and pollsfor more real world usage data.

FIG. 7 illustrates exemplar mobile device interactions in the context ofa use module. More specifically, FIG. 7 represents the process in thereal world use module that analyzes the clicking patterns of clinicaltrial subjects in order to better arrange the elements on the screen.Illustration (A) shows the original arrangement of the elements on thescreen where they are numbered to represent the order in which they aremeant to be completed. The numbered stars in illustration (B) show theclick location and order. Illustration (C) shows the elements rearrangedto coincide with the click pattern being observed in the real world.

FIG. 8 illustrates an application simulation interface. Illustration (A)shows the screen as it has been designed in the construction software.In this example the user has selected the middle section to revise. Themodule options from the element database are displayed. In this case,the user can remove the module, revise the colors, change the options orchange the position of the element on the screen. Different elementswill have different questions, for example a text question may allow theuser to reword the question. In this example the user has selectedrevise colors. Illustration (B) shows each of the color boxes now with adrop down menu. The user has selected the yellow color to change andtheir available options are displayed. At any point the user can selectthe “End” button which will prompt the construction software to get userapproval to launch the application availability. The user can continueto navigate through the simulation making as many edits as they likebefore selecting the “End” button.

FIG. 9 illustrates an application review interface. More specifically,these figures represent the review module screen of the applicationbuilding interface on the user terminal. The first box on the left listthe elements determined to be required for the study by the constructionsoftware. Each element has a selectable box that allows the user toselect to include or not include a given element. In this example theuser deselected required element 17. This would take the user out of thereview module and back to the question ordering module. The study cannotbe launched without all required elements, so the user will need toeither adjust the parameters of the study in the question orderingmodule or include the required element(s).

The second column contains all relevant elements that are optional. Thethird box shows the list of clinical or consumer medical monitoringdevices that can provide data relevant to the study. In this example theuser selected clinical device 2. The selection of a clinical device willprompt the system to distribute that device to all trial subjects. Theuser also selected consumer devices 1, 3, and 7. When trial subjects loginto the application they will be asked if they have one of those threedevices, and if they wish to allow the app to collect data from thatdevice for the purposes of the clinical trial. The fourth columncontains all backend documentation available, with the documents deemedrelevant preselected. The user can select additional documentation toinclude from this screen.

FIG. 10 illustrates a usability database. The illustrated table is forpatient application #123 and the data is collected from subject mobiledevices and the averages for time spent, number of clicks, andcompletion percentage are calculated by the real world use module andstored in columns three, four, and five. The first column contains thename of the element/question/screen/login. The second column containsthe number of data points used to calculate the averages in columnsthree, four and five. The number of data points is used to determine ifthe sample size is large enough to determine that the data in columnsthree, four and five are statistically significant, and should be actedupon.

FIG. 11 illustrates a building database. This first column as shown hasthe identification number for an application that was constructed usingthis system. The rest of the columns are all of the elements availablefrom the element database and what order they appear in the applicationspecified in the first column.

The foregoing detailed description of the technology has been presentedfor purposes of illustration and description. It is not intended to beexhaustive or to limit the technology to the precise form disclosed.Many modifications and variations are possible in light of the aboveteaching. The described embodiments were chosen in order to best explainthe principles of the technology, its practical application, and toenable others skilled in the art to utilize the technology in variousembodiments and with various modifications as are suited to theparticular use contemplated. It is intended that the scope of thetechnology be defined by the claim.

1. A method for remote clinical trial organization, the method comprising; receiving a response for at least a first question from a hierarchy of questions designed to identify one or more elements necessary to complete a clinical trial in an application based testing environment; positing at least a second question from the hierarchy of questions, the second question based on the received response for the at least first question, whereby the collective responses to the questions are used to access a database of elements for constructing the application for the clinical trial application, including any clinical and consumer medical monitoring devices necessary for the trial, wherein in the database is updated with future modules and applications related to self-construction of the application; processing data collected from a trial subject utilizing the application for the clinical trial and any corresponding clinical and consumer medical monitoring devices, the data processed at a cloud-based server environment including at least one server from a server farm and that stores and instantiates a software platform that organizes the clinical trial through authoring of the application and that further operates in conjunction with the clinical trial; and modifying the clinical trial application in real-time responsive to the processed data collected from the trial subject.
 2. The method of claim 1, further comprising executing a real-time simulation of the application before launching the clinical trial application and collecting data from the trial subjects utilizing the clinical trial application.
 3. The method of claim 2, wherein the real-time simulation further modifies the clinical trial application prior to launching the clinical trial application.
 4. A system for building a clinical trial application, the system comprising: a user device that provides a prompt to build a clinical trial application and clinical trial requirements related to the same; and a software platform that is stored on and instantiates in a cloud-based server environment including at least one server from a server farm, the instantiation responsive to a prompt from the user device to build the clinical trial application including a selection of clinical and consumer medical monitoring devices necessary for a clinical trial, whereupon the software platform executes to posit a series of iterative questions from a hierarchy of questions that drive the building of the clinical trial application in accordance with the clinical trial requirements, each response to each question from the series of iterative questions determining a next question in the series, and wherein in the software platform is updated with future modules and applications related to self-construction of the application.
 5. The system of claim 4, the instantiated software platform further executable such that it builds the clinical trial application in real-time.
 6. The system of claim 5, the instantiated software platform further executable such that the clinical trial application is built responsive to responses to the series of iterative questions.
 7. The system of claim 5, the instantiated software platform further executable such that it simulates the clinical trial application.
 8. The system of claim 7, wherein the simulation occurs in real-time.
 9. The system of claim 5, wherein the user device further provides data to the software platform concerning execution of the clinical trial application.
 10. The system of claim 4, the system further comprising additional user devices not involved in building the clinical trial application and that exchange data with the software platform concerning execution of the clinical trial application.
 11. The system of claim 10, the instantiated software platform further executable to modify the clinical trial application responsive to information exchanges with the additional user devices.
 12. The method of claim 1, wherein modifying the clinical trial application includes modification of a variable.
 13. The method of claim 12, wherein the variable is time.
 14. The method of claim 12, wherein the variable is an option for user entry.
 15. The method of claim 12, wherein the variable is an option for user selection.
 16. The method of claim 12, wherein the processed data includes time.
 17. The method of claim 12, wherein the processed data includes a user entry.
 18. The method of claim 12, wherein the processed data includes a user selection.
 19. The method of claim 12, wherein modifying the clinical trial application occurs after identifying a user trouble spot.
 20. The method of claim 12, wherein modifying the clinical trial application includes redesign of a user interface.
 21. The method of claim 12, wherein modifying the clinical trial application includes modifying a process flow.
 22. The method of claim 12, wherein modifying the clinical trial application includes a change to application usability. 